Summary

BigQueryDriver.stream wires its returned rowStream to the underlying @google-cloud/bigquery source stream via stream.pipe(rowStream). By design, Node's pipe() forwards data/end events but not error events. When BigQuery returns an HTTP error mid-stream (e.g. a type-coercion rejection like No matching signature for operator = for argument types: TIMESTAMP, DATE), the source stream's 'error' event has no listener — Node's default 'error' handler fires (processTicksAndRejections) and the cubejs-server process exits with code 1. Every BI session connected to that pod is torn down with server closed the connection unexpectedly.

The non-streaming path (driver.query) is unaffected because the rejection propagates through await and is caught by the cube native bridge's top-level try/catch. The streaming path returns the rowStream synchronously, so await resolves before the HTTP call fires — the bridge has no chance to catch the rejection.

Fixes #10875.

Changes

Switches BigQueryDriver.stream from stream.pipe(rowStream) to stream.pipeline(stream, rowStream, () => {}) from node:stream. This fixes both observed defects:

1. Source error forwarding — pipeline auto-destroys rowStream with the underlying error → bridge's rowStream.on('error', ...) handler fires → wire layer emits structured Postgres ErrorResponse (XX000) carrying the verbatim BigQuery message.
2. Consumer-side cancellation — destruction of rowStream (client cancellation, severed BI session) now destroys the source too, preventing the driver from paging results into the void after the consumer has gone away.

Implementation Details

• pipeline() is in Node's stable API since v10 (callback form). Cube's Node engine constraint is well clear of this.
• Callback is intentionally a no-op: pipeline already destroys rowStream with the error, and the callback exists solely to satisfy the signature and prevent an unhandled rejection inside pipeline itself.
• Promise-based stream/promises.pipeline is the wrong choice here — awaiting it would block returning rowStream until the entire query completes, buffering the whole result set in memory. Callback form keeps the existing synchronous-return contract.

Testing

Unit tests (new — packages/cubejs-bigquery-driver/test/BigQueryDriverStreamError.test.ts)

Two synthetic-source tests using PassThrough streams (no real BigQuery needed):

• forwards source-stream errors to the returned rowStream — emits an error on a mock source and asserts rowStream receives it.
• propagates rowStream destruction back to the source stream — calls rowStream.destroy() and asserts the mock source's destroyed flag is set.

Both tests time out when the fix is reverted to bare stream.pipe() (proves they catch the regression).

End-to-end verification against real BigQuery

Verified via the cube SQL API + psql (cube v1.6.46 with patched BigQueryDriver.js overlaid into a running container):

Wire-level behaviour is now identical to the non-streaming SQL API (same XX000 SQLSTATE, same pg.DatabaseError shape, same verbatim BigQuery message reaching the client).

Compatibility & risk

• No behavioural change on the success path (verified by the 100k-row streaming check).
• Failure path now surfaces a structured Postgres error where it previously crashed the process — strict improvement.
• stream.pipeline is the textbook Node primitive for this exact wiring. No new dependencies.